chore: add license headers and CI - #2929

…n-minor-and-patch-5f24554eda

chore(deps): bump the version-minor-and-patch group across 1 directory with 12 updates

* chore: backfill Apache license headers in ts/js files

Claude-Session: https://claude.ai/code/session_013dz9GhC3metut6HFswPavu

* ci: enforce Apache license headers with addlicense

Adds a license job to the Validate workflow that runs google/addlicense
in check mode over tracked ts/js files. Run npm run license:fix locally
to add missing headers.

Claude-Session: https://claude.ai/code/session_013dz9GhC3metut6HFswPavu

* ci: pin validate workflow actions to commit SHAs

Required by zizmor unpinned-uses mandatory policy.

Claude-Session: https://claude.ai/code/session_013dz9GhC3metut6HFswPavu

* ci: restrict validate workflow to read-only permissions

Resolves zizmor excessive-permissions finding.

Claude-Session: https://claude.ai/code/session_013dz9GhC3metut6HFswPavu

* chore: harden addlicense script

NUL-separated file list for filenames with special characters, and
reject unknown modes instead of defaulting to fix.

Claude-Session: https://claude.ai/code/session_013dz9GhC3metut6HFswPavu

…icts

Add release workflow

Fix release kit action

Kits should be published from the kits branch

Use NPM provenance instead of wombat

This helps debug action failures when several releases are happening at once and they fail early

Print inputs as the first step of release-kits

## Summary

`npm publish --provenance` requires `repository.url` to resolve to the
GitHub repo that built the package. Two BigQuery script packages
declared a bare `github.com/firebase/extensions.git` — no scheme, so npm
can't normalise it and provenance fails.

Prefixed both with `git+https://`, matching
`firestore-bigquery-change-tracker`, which already publishes fine:

- `@firebaseextensions/fs-bq-schema-views`
- `@firebaseextensions/fs-bq-import-collection`

Broken since `--provenance` was added in March 2026. No other
`package.json` on `next` is affected.

Syncs release-kit.yaml byte-for-byte with the version that landed on
kits in #2990. This copy never executes (Release Kit is always
dispatched from kits; next has no kits/ directories); it only lists the
workflow in the Actions UI, and it had drifted to show the old broken
versioning logic. No behavior change. Will need re-syncing if #2991
lands on kits.

Syncs release-kit.yaml byte-for-byte with the #2993 version on kits
(trusted publishing, checkout/push/release pinned to kits). The #2992
copy on next authenticated via the removed NPM_TOKEN and checked out the
dispatched ref, so dispatching from next failed at the test job. The
#2993 file is dispatch-ref-agnostic, making the two copies safely
identical. No behavior change beyond fixing dispatch-from-next.

chore(ci): print inputs at start of release-kit workflow

## The bug

The retry guard was an `async` function called without `await`, so it
was always truthy and every insert failure retried with
`ignoreUnknownValues: true`. Unknown fields were dropped and the write
reported success. Since 2020 (`2de70201`), untested.

## The fix

The retry now removes only the columns BigQuery named, and only the ones
we add to existing tables (`document_id`, `old_data`, and `path_params`
with `wildcardIds`). Anything else fails the insert and backs up the
full row.

Two adjacent bugs go with it: `settings()` was called on every failure
though it may only be called once, so every backup after the first
threw; and `error_details` was always empty.

## Testing

52 new offline tests, `tsc --noEmit` clean, plus verified against a live
BigQuery instance.

## To decide

Allowlisting `document_id` costs a duplicate row in the legacy `_latest`
view, taken because those tables already duplicate every pre-upgrade
row. Needs a CHANGELOG note and a tracker version bump.

---------

Co-authored-by: Jacob Cable <jacobcable94@gmail.com>

…d clustering sync (#2817)

Fixes #2194. (#2801, the `db.settings()` guard, was originally part of
this branch but landed on next with #2937; this PR no longer touches
that file.)

#2194: `tableRequiresUpdate` always returned true, via two accidental
triggers: `JSON.stringify(config.clustering)` gives `"null"` vs the
table's `"[]"`, and `fields.find(...)` fed `undefined` into a boolean
comparison. Fixed with `config.clustering || []` and `fields.some(...)`.
The `find` -> `some` change is behavioral, not cosmetic: clustering sync
on existing tables depended on the always-true trigger, because
`updateClustering` mutated the shared metadata before
`tableRequiresUpdate` compared it (desired vs desired). A third commit
moves `updateClustering` after the check, inside `shouldUpdate`. The
`some` fix has no behavioral regression guard (offline tests pass
booleans directly, and the live suites assert final table state, which
the spurious update also produced), so `fields` is now typed
`TableField[]` and a revert to `find` fails compilation.

Rebased onto next after #2937 merged. The behavior change disclosed
earlier is now narrower: `tableRequiresUpdate` gained a trigger that
fires when the configured custom partition column is missing from the
table's schema, so the column is added by a real metadata update on the
next initialize instead of by the old spurious path, and the trigger
stops firing once the column lands. What remains: an insert racing the
column's schema propagation fails terminally with its rows backed up
intact, since the column is deliberately not stripped for a lag retry (a
null there misfiles the row into the wrong partition permanently).

Verified against live BigQuery: clustering, insertRetry, backupSettings,
and checkUpdates suites all pass; clustering, checkUpdates, and
partitioning (with `RUN_BIGQUERY_INTEGRATION_TESTS=true`) re-run after
the review follow-up.

feat(release-kit): add use firebase-functions RC checkbox and validation